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ABSTRACT 


\ 

\ 

-"  The  vulnerability  of  the  software  process  development 
to  errors  or  omissions  in  the  requirements  specification  is 
well  known.  The  goal  of  this  program  is  to  develop  user  aids 
that  will  help  a  neophyte  user  to  work  with  an  experienced 
software  analyst  in  developing  requirements  specifications. 

The  initial  experiment,  completed  this  year,  is  an  investigation 
of  the  utility  of  cost  aids  as  a  function  of  task  complexity. 

The  neophyte  user  developed  various  designs  and  requested  cost 
information  for  those  designs  which  were  presented  in  various 
forms.  The  aids  permitted  the  user  to  recall  detailed  informa¬ 
tion  on  previous  designs,  21s  well  as,  an  automatic  analysis  of 
previous  designs  to  reveal  the  most  cost  effective  design  and 
suggest  new  designs. 


INTRODUCTION 


Although  errors  in  software  occur  in  all  stages  of  the 
software  life  cycle,  errors  that  occur  early  in  the  cycle, 
especially  in  the  preparation  of  software  requirement  specifi¬ 
cations,  are  critical  because  they  are  difficult  to  detect.  Also, 
the  cost  of  correcting  a  requirement  specification  error  increases 
as  its  detection  is  delayed  through  subsequent  software  development 
states.  A  further  complication  is,  according  to  Boehm  (1976)  who 
voices  a  commonly  stated  observation,  that  most  errors  in  soft¬ 
ware  development  occur  in  the  early  stages  and  frequently  are 
errors  of  omission. 

An  incomplete  or  inaccurate  requirement  specification  (RS) 
causes  difficulty  in  other  software  development  steps:  systematic 
top-down  design  suffers  from  the  lack  of  an  incomplete  top  (specifi¬ 
cation),  testing  is  inadequate  due  to  lack  of  a  complete,  accurate 
requirement  to  test  against,  and  project  management  suffers  for  the 
lack  of  a  complete  statement  against  which  progress  can  be  measured. 

Existing  methodologies,  designed  to  improve  software  quality, 
unfortunately  apply  only,  to  the  design  (preliminary  and  detailed 
design)  and  subsequent  steps.  These  methodologies  are  directed 
to  improving  the  steps  in  the  software  development  process  that 
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occur  after  the  requirements  have  been  specified  and  therefore 
neglect  the  process  of  producing  the  RS.  The  imbalance  in 
the  distribution  of  software  methodologies  and  aids,  which  favor 
software  design  and  test  over  preparation  of  RS,  is  illustrated 
by  the  lack  of  a  requirement  preparation  "block’'  in  typical 
descriptions  of  the  software  development  process  as  shown  in 
Figure  1 .  The  process  is  typically  visualized  as  beginning 
with  a  requirements  block  -  as  if  to  indicate  that  the  process 
starts  with  the  (supposedly  existing)  RS.  Improvements  in  the 
requirements  development  process  have  been  generally  limited 
to  development  of  notational  methods  for  recording  the  require¬ 
ments.  Actually,  of  course,  the  process  starts,  as  shown 
in  Figure  2,  with  the  user  needs,  which  may  or  may  not  be  well 
understood  by  the  user,  from  which  the  RS  must  be  developed. 

It  is  this  process,  the  transformation  of  vague  user  needs  into 
precise  RS,  often  with  the  user  working  with  a  software  expert, 
that  is  of  interest  here. 

Background 

At  present,  the  tools  available  for  software  development 
fall  into  one  of  two  classes:  one  class  included  the  well-known  design 
aids  such  as  Structured  Design  (Yourdon  &  Constantine,  1979),  Jackson's 
Method  (Jackson,  1975),  and  Logical  Construction  of  Programs  (Warmer, 
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Figure  2.  Actual  Software  Life  Cycle 
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1974,  and  Orr,  1977).  These  are  design  aids  that  use  RS, 
which  are  assumed  to  be  correct,  as  a  starting  point. 

The  other  class  of  aids  provides  a  sturcture  which  can 
be  used  to  record  and  analyze  the  RS .  In  this  latter  class  is 
a  system  called  ISDOS  (Teichroew  &  Hershey,  1979)  which  used 
a  problem  statement  language  (PSL)  and  a  problem  statement 
analysis  (PSA).  ISDOS  permits  a  formal  description  of  the 
system  in  terms  of  entities,  classes,  and  relationships, 
and  automatically  provides  summaries  such  as  problem  state¬ 
ments,  directories,  hierarchical  structure  reports,  graphical 
summaries  of  data  flow  and  relationships.  Another  example 

in  the  class  is  a  method  called  Software  Requirements  Engineering 
Programs  (SREP)  described  by  Boehm  (1976)  in  a  survey  of 
methodologies.  SREP  uses  the  data  management  system  of  ISDOS 
and  produces  functional  simulations  from  requirements  statements. 
It  is  also  used  for  configuration  control,  traceability  from  require¬ 
ments  to  design,  and  report  generation.  A  further  method  in  the 
second  class.  Structured  Analysis  for  Requirements  Definition,  is 
described  by  Ross  and  Schoman  (1977).  Part  of  that  method  is  a 
Structured  Analysis  and  Design  Technique  (SADT)  for  analyzing 
requirements  using  graphical  techniques.  All  these  methods 


contain  a  common  defect:  that  of  providing  a  structure  for  recording 
the  requirements,  and  then  for  analyzing  those  requirements  but  not 
for  supporting  the  process  of  developing  the  RS  from  a  user's  needs. 

In  an  extensive  survey  and  review  of  the  status  of  software 
requirements  methods,  Ramamoorthy  &  So  (1978)  identify  the  same 
requirements  development  problems  referred  to  above;  namely  that 
a  large  percentage  of  the  total  errors  in  software  development  occur 
in  the  requirements  specification,  and  that  these  errors  cause  serious 
problems  leading  to  high  costs,  unresponsive  products,  slippage  of 
production  schedule,  and  difficulty  in  system  operation  and  maintenance. 
Further,  they  briefly  describe  a  number  of  methodologies  for  RS 
documentation  and  for  aiding  the  software  design  process. 

Research  on  Development  of  Requirements  Specifications 

Miller  (1978)  investigated  the  interactive  process  between 
a  user  (client)  and  software  designer  in  analyzing  the  user’s  needs, 
establishing  RS,  and  developing  a  software  design.  His  description 
of  the  process  uses  four  steps,  and  is  presented  below.  For  ease 
of  reference  in  what  follows  we  give  the  steps  described  by  Miller 
even  though  interest  here  is  limited  to  the  first  two  steps. 
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Miller's  four  steps  are: 


t.  Problem  understanding,  arriving  at  a  general 
agreement  as  to  what  are: 

a.  the  goal  objectives, 

b.  the  system  or  environments  involved, 

c.  constraints  (on  performance  delivery  costs,  etc.)> 

d.  the  resources  available  for  system  design  development 
2.  Functional  requirement  specification  determining 

precisely  what  the  final  product  must  be  like 
including: 

a.  every  important  aspect  of  its  internal  performance, 

b.  the  characteristics  of  its  embedded  operator/user 
population, 

c.  relationship  to  other  systems  and  environments,  and 

d.  development  constraints 

.  Overall  high  level  design  translating  the  functional 
requirements  into  a  comprehensive  design  which 
specifies  the  major  components  of  the  to-be  developed 
product,  and,  for  each  describes: 

a.  the  goals  to  be  achieved  by  the  component, 

b.  the  character istics  of  all  factors  to  which  the 
component  is  to  be  sensitive,  i.e.,  the  input. 


c.  the  characteristics  of  the  effects  the  component 
must  achieve,  i.e.,  the  output, 

d.  the  internal  structures  of  the  component,  i.e., 
internal  structures,  and 

e.  the  general  principle  of  any  operation  sequences 

»  within  the  component  information  processing 

procedures . 

4.  Detailed  design  suitable  for  prototype  development. 

The  steps  of  interest  here  are  the  first  two  steps  which 
start  with  the  initial  discussions  of  the  problem  with  the  client 
and  end  with  preparation  of  a  formal  RS.  We  do  not  treat  the 
high  level  or  detailed  design  steps. 

Miller  investigated  the  nature  of  the  process  of  transforming 
the  client’s  vague  initial  specification  into  a  format  specification. 

He  describes,  in  particular,  the  function  of  the  client  and  software 
designer  by  describing  the  interchange  between  the  two,  and  he 
suggests  that  the  designers  often  use  the  technique  of  suggesting 
particular  pieces  of  equipment  or  procedures  that  might  be  (or  at 
least  approximate)  an  acceptable  solution.  The  client,  in  rejecting 
some  of  these  suggestions  will  modify  his  own  requirement  statements . 
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As  a  result  of  this  interchange  the  client  will  clarify  his  own 


understanding  of  the  problem  and  they  will  mutually  arrive  at 
an  acceptable  solution. 

Miller  points  out  that  the  role  of  the  designer  is  to  provide 
facts  about  the  real  world  in  terms  of  properties  of  equipment 
and  alternative  solutions,  as  well  as  to  ask  questions  which, 
while  providing  clarification,  frequently  may  have  the  effect 
of  inducing  the  client  to  identify  a  new  problem  or  a  better 
conceptualization  of  the  present  problem.  He  further  identifies 
a  sequence  of  six  states  which  the  client  and  designer  use 
sequentially.  The  six  states  are: 

1 .  Goal  statement 

2.  Goal  elaboration 

3.  (Sub)  Solution  outline 

4.  (Sub)  Solution  elaboration 

5.  (Sub)  Solution  explication 

6.  Agreement  on  (Sub)  solution. 

Miller  indicates  that  this  state  sequence  is  used  iteratively,  but  that 
sometimes  the  sequence  is  truncated  to  start  a  new  one  to  pursue 
a  different  solution. 
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The  results  by  Miller  suggest  that  the  process  of  transforming 
user's  needs  into  a  formal  statement  of  requirements  may  benefit 
from  the  interchange  between  a  client  knowledgeable  about  his  own 
needs  and  a  software  designer  knowledgeable  about  the  capabilities  of 

computer  systems.  According  to  this  model,  the  client's  concept 
of  his  needs  grows  as  a  result  of  the  interchange  and  he/she 
becomes  aware  of  new  and  different  solutions  to  his/her  problem. 

New  solutions  evolve  iteratively  into  one  mutually  accepted  by 
both  the  client  and  designer  as  being  complete  and  feasible. 

The  question  then  arises  as  to  the  need  for  an  interchange 
to  evolve  the  feasible  solution.  For  instance,  when  preparing 
RS  for  a  large  computer  system,  it  may  not  be  possible  for 
all  the  user-clients  to  have  a  useful  interchange  with  one  or 
more  designers.  Not  only  would  these  be  multiple  client- 
designer  interchanges,  but,  there  would  be  multiple  interchanges 
(discussions  of  tradeoffs  among  the  many  interests)  among 
the  user-clients,  and  perhaps  multiple  interchanges  among 
several  designers.  At  present,  when  specifications  for  develop¬ 
ment  of  a  large  software  system  are  considered,  the  user-client 
develops  formal  specifications  without  extensive  interchange 
concerning  the  ultimate  designs.  The  RS  are  then  presented 
to  designers  -  perhaps  m  the  form  of  a  request-for-quotation 
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RFQ).  Such  a  procedure  which  is  often  used  for  large  software 
projects  is  formal  and  prohibits  the  informal  interchange  of  the 
type  described  above  that  might  be  used  to  advantage  for  a 
small  software  system . 


1 1 


METHOD  OF  APPROACH 


In  order  to  investigate  the  process  by  which  an  individual 
not  skilled  in  the  art  of  software  would  develop  software 
RS,  a  series  of  four  experiments  are  planned.  Each 
experiment  involves  the  design  and  evaluation  of  one  or  more 
aids.  These  are: 

1.  Aids  to  assist  in  finding  the  minimum  cost  system. 

2.  Aids  to  assist  in  generating  complete  specifications. 

3.  Aids  to  assist  in  building  a  vocabulary. 

4.  Aids  to  assist  the  neophyte  users. 

Experiment  Task:  An  Inventory  Control  Problem 

The  experiment  task  is  the  development  of  a  software 
specification  for  an  inventory  control  problem  by  means  of  a  re¬ 
corded  interaction  between  a  user  and  a  software  designer. 

Problem:  Inventory  Control 

An  important  aspect  of  inventory  control  is  the  maintenance 
of  records  of  present  stock,  amount  of  stock  on  order,  recent 
transactions,  and  transaction  histories.  At  periodic  intervals, 
daily,  weekly,  or  monthly,  the  old  master  file  is  read,  transactions 
recorded,  new  stock  levels  computed,  new  stock  order  recommenda¬ 
tions  and  other  reports  produced,  and  a  new  updated,  master  file 
produced.  Specifications  for  a  computer  program  to  provide  the 


ADP  inventory  control  would  include  specification  of  acceptable 
transactions,  rules  for  entering  new  data  or  deleting  old  data, 
rules  for  computing  stock  levels,  rules  for  computing  purchase 
recommendations  and  computing  stock  history  functions,  rules  for 
outputting  reports  and  a  new  master  file. 

The  particular  inventory  control  problem  considered  for 
illustration  of  the  research  method  is  the  processing  of  the  old 
master  file  with  current  transactions  to  produce  a  new  master 
file.  The  old  and  new  master  files  are  on  magnetic  tape.  The 
current  transaction  file  is  in  main  memory. 

Various  tradeoff’s  involving  data  accuracy  and  data 
protection,  as  well  as  speed  of  the  process,  must  also  be  considered 
in  preparing  the  software  specifications.  Software  specifications  do 
not  delineate  the  way  a  particular  feature  is  to  be  implemented; 
specifications  state  the  combination  of  features  required  in  the 
software  product.  Consequently,  the  specification  can  consist 
of  logical  functions  which  indicate  that  combination  of  features. 

A  score  indicating  the  quality  of  the  RS  is  the  number  of 
factors  that  are  included  in  the  specification  that  either  were  not 
included  in  the  problem  statement  or  should  not  be  included  in 
the  specification  because  of  the  high  cost  required  to  implement 
them. 
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Participants 

(Two  participants  in  each  experiment  trial) 

•  One  participant,  not  an  experienced  analyst/ 
programmer,  but  experienced  in  a  particular 
subject-matter  field,  is  the  "user.” 

•  Another  participant,  an  experienced  analyst/ 
programmer,  is  the  "software  designer." 

Procedure 

The  participants  are  given  instructions  individually  via 
video  tape  presentations.  These  instructions  include  procedures, 
goals,  and  the  method  of  scoring  to  be  used  in  evaluating  the 
experiment.  Following  the  presentation,  a  written  inventory 
control  problem  statement  is  given  to  the  user.  The  problem 
statement  identifies  the  various  functions  that  could  be  included  in 
the  specification  and  the  relative  importance  of  each  function. 
Further,  the  user  is  told  that  the  present  objective  is  to  interact 
with  a  designer  to  jointly  develop  a  software  specification  for  the 
problem.  The  user  is  instructed  that  all  necessary  features 
(identified  as  necessary  in  the  problem  statement)  of  the  process 
plus  additional  features  (that  are  also  identified  in  the  problem 
statement)  that  are  achievable  at  low  cost  should  be  included  in 


the  system  specification.  The  participant  is  also  told  that  additional 


factors  which  may  result  in  programming  delays  or  otherwise 
incur  a  large  additional  cost  are  not  to  be  included  in  the  specifi¬ 
cation.  Thus  the  user's  task  is:  to  understand  the  problem, 
to  establish  the  communication  with  the  designer,  to  work  with 
the  designer  to  determine  what  features  must  be  included  in  the 
specification  and  what  additional  features  can  be  included  in  low 
cost,  and  to  insure  that  the  necessary  functional  relationships 
among  problem  features  are  included  in  the  software  specification. 

The  designer  is  also  given  instructions  individually  via 
video  tape.  He/she  is  given  the  basic  vocubulary  and  information 
on  the  capability  of  the  operating  system  to  be  used  for  the  software 
system.  He/she  is  instructed  to  establish  a  communication  with 
a  user,  offer  information  regarding  feasibility  and  relative  cost 
(programming  effort  and  program  efficiency)  of  various  features. 
Finally,  he/she  is  instructed  to  prepare  a  software  specification 
for  the  process. 

After  a  short  period  of  time  in  which  the  user  reviews 
the  problem  statement,  the  user  and  designer  are  permitted  to 
communicate  via  a  keyboard  link  (computer  controlled)  to  exchange 
information  concerning  the  problem  and  to  arrive  at  a  solution 
in  the  form  of  the  software  specification. 


Progress  to  Date 

For  the  first  experiment  identified  above,  aids  were 
designed  to  facilitate  specification  of  a  minimum  cost  system. 

The  participants  interacted  with  a  simulated  software  expert  which 
provided  cost  information  feedback  for  each  of  the  participant’s 
trial  specifications.  The  procedure  used  to  find  the  requirements 
specification  for  the  least-cost  system  is  as  follows:  The 
participants  input  a  trial  RS  and  received  as  feedback  the  cost 
of  that  system.  Next  he/she  reviewed  the  specification  and 
the  associated  system  cost  along  with  any  other  specifications 
(and  their  system  costs)  previously  input.  Based  on  that  review, 
the  RS  were  modified  in  an  attempt  to  specify  a  lower  cost  system. 
This  is  an  iterative,  "cut  and  try"  procedure  in  which  the  user 
employed  knowledge  of  the  cost  of  previous  specifications  and 
knowledge  of  the  function  of  system  parts  to  develop  the  RS 
for  the  next  iteration. 

This  iterative  process  continued  until  the  total  allowed 
session  time  was  used  (1  hour)  or  the  user  believed  that  the 
requirements  for  the  minimum  cost  system  had  been  specified. 

Three  levels  of  cost  feedback  aids  were  used.  The  base 
level  cost  feedback  configuration,  where  a  minimum  of  cost  processing 
and  feedback  was  provided,  gave  the  user  information  only  on  the 
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total  cost  for  the  specification.  The  next  level  of  aid  processing 
provided  cost  information  for  each  part  of  the  system  as  well  as 
the  total  cost.  And  finally,  at  the  highest  level,  users  were  given 
the  information  from  the  first  two  levels  plus  an  additional 
analysis  showing  the  relationship  between  cost  and  the  elements 
of  the  RS  previously  entered. 

The  data  has  been  collected  for  this  first  experiment  and 
the  data  analyses  is  now  in  progress. 

Future  Plans 

In  addition  to  the  data  analysis  on  the  first  experiment, 
work  has  been  started  on  vocabulary  building  aids  in  which  two 
individuals  will  work  together  by  inputting  data  on  separate  but 
communicating  terminals  to  first  build  a  working  vocabulary  and 
then  to  develop  a  requirements  specification.  The  aids  will  assist 
the  two  participants  to  rapidly  build  efficient  vocabularies  for 
the  requirements  specification.  Following  completion  of  the 
vocabulary  building  experiment,  the  aids  for  generating  complete 
(and  accurate)  RS  and  aids  to  assist  the  neophyte  user  will  be 
developed  and  tested. 
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